Prerequisites for the IBM MQ Monitoring Agent

Prepare your environment for seamless, secure monitoring with the Nodinite IBM MQ Monitoring Agent. These prerequisites also ensure the agent can report correctly into the Nodinite Control Center. On this page, you will:

• ✅ Discover all software and system requirements for a successful installation
• ✅ Learn the exact firewall and network settings for reliable agent communication
• ✅ Understand the Windows and IBM MQ user rights needed for secure operations
• ✅ Get expert tips to avoid common setup pitfalls and ensure business continuity

A high-level diagram showing the Nodinite IBM MQ Monitoring Agent communicating with the IBM MQ Queue Manager over TCP.

You can install the agent on-premise using TCP/IP for local network access or in the cloud/off-site using Microsoft Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs').

Software Requirements

Versions 7.0.4 and later require .NET 10 Hosting Bundle.

.NET 10 minimum OS: Windows Server 2012 / 2012 R2.

Version History: .NET and IBM MQ Client Requirements

Key Point

Assembly redirect configuration (binding redirects for AMQMDNET.DLL) was only required for .NET Framework versions. Modern .NET 10 versions do not require assembly binding configuration.

Note

Version 8.0.4 is NOT recommended due to IBM MQ bugs with temporary queues not being removed by the queue manager. Please upgrade if you are on this version.

Assembly Redirect Configuration (AMQMDNET.DLL binding redirects) is NOT required for v7.0.4+ because the agent now uses .NET 10. Legacy versions (v5.4-v7.0.3) using .NET Framework 4.8 may need assembly configuration—see Troubleshooting for historical guidance.

What firewall settings are required for the IBM MQ Monitoring Agent?

Where you install the Nodinite IBM MQ Monitoring Agent in relation to the Nodinite Monitoring Service and your IBM MQ Queue Managers determines your firewall configuration. The diagram shows every host involved, with the agent on its own server; each arrow starts at the side that opens the connection.

Network diagram: the Monitoring Service calls the agent, the agent connects to the Queue Manager listener and, for IIB/ACE logging, posts Log Events to the Log API. Dashed arrows are optional hops.

Note

When the agent runs on the Core Services Server (the typical installation), you need no firewall rule between the Monitoring Service or the Log API and the agent.

Between the Monitoring Service and the IBM MQ Monitoring Agent

The Monitoring Service opens every connection; the agent never calls it. On Windows Server, Nodinite v7 hosts the agent as its own IIS web site, on a port you set per environment in the Nodinite Portal (Servers step).

Option: Service Bus Relaying (cloud or hybrid)

Use Service Bus Relayed connections when Nodinite and the agent are on different networks. Both sides connect outbound to the Azure Relay namespace, so neither server needs an inbound rule. Nodinite uses the same principle as the on-premises data gateway; see 'Adjust communication settings for the on-premises data gateway' and the 'Azure Relay FAQs'.

Between the IBM MQ Monitoring Agent and the IBM MQ Queue Managers

Required for monitoring Queue Managers, queues, topics, channels, and listeners.

Tip

Verify the listener port of each Queue Manager to monitor. For TLS certificates, review Configuring TLS security for IBM MQ.

Between the IBM MQ Monitoring Agent and the Log API

Required only for IBM Integration Bus Logging (see IBM Integration Bus Logging Prerequisites).

Between the servers and DNS

Important

Stateful Firewalls: Most Windows Firewall implementations are stateful, so response traffic for established outbound connections is allowed automatically. The inbound response rules above are for reference and troubleshooting.

What Windows User Rights does the IBM MQ Monitoring Agent require?

The agent installs as a Windows Service—usually on the Nodinite application server. Virtual machines are supported.

Service Account Options ^{New 7.0.4}:

• Group Managed Service Account (gMSA) - Recommended for automated password management. See Configure Group Managed Service Accounts (gMSA) for setup instructions.
• Traditional Account - Use a local named account or domain account (preferred).
  • Follow the 'How to set logon as a Windows service right' user guide for detailed instructions.

Important

For IBM MQ XA transaction support and queue manager connectivity, you must add the service account to the local Administrators group on the server where the agent runs. This elevated permission is required for MSDTC and IBM MQ client operations.

What IBM MQ User Rights does the IBM MQ Monitoring Agent require?

For each IBM MQ Queue Manager to monitor, the configured account must have at least read rights. Some operations require additional rights for changing state, consuming messages, or purging queues.

You can configure which user account to use for each IBM MQ Queue Manager. See the Configuration user guide for more information.

• Member of the MQM user group (local or domain group where IBM MQ Queue manager is installed) OR
• Least privileges - See the sections below for detailed explanations and optimized permission sets

Understanding IBM MQ Permissions

Before configuring permissions, it's important to understand what each permission flag does:

IBM MQ Object Types

• qmgr - Queue Manager (the IBM MQ instance itself)
• q - Queues (where messages are stored)
• channel - Channels (communication paths)
• clntconn - Client Connection Channels (remote client connections)
• listener - Listeners (network listeners for incoming connections)
• topic - Topics (publish/subscribe messaging)
• process - Processes (application definitions)
• namelist - Namelists (lists of object names)
• authinfo - Authentication Information (security configurations)
• service - Services (Windows services or Unix processes)
• comminfo - Communication Information (multicast configuration)

Wildcard Pattern

• "**" - Matches all objects of the specified type

IBM MQ Permission Requirements Explained

The table below explains what each permission command does and whether it's required for Nodinite monitoring and management:

Note

About PCF Commands and Security:

The two commands above (SYSTEM.ADMIN.COMMAND.QUEUE and SYSTEM.DEFAULT.MODEL.QUEUE) use PCF (Programmable Command Format), which is IBM's official administrative interface used by all monitoring tools (IBM MQ Explorer, Console, REST API, and Nodinite).

Key Points:

• ✅ Object-level security is enforced - Access to SYSTEM.ADMIN.COMMAND.QUEUE does NOT bypass permissions. IBM MQ still checks permissions on queues, topics, channels, and listeners.
• ✅ Standard IBM interface - This is the only way to programmatically query IBM MQ. There is no alternative.
• ✅ Temporary queues are safe - Used only for command responses (metadata, not business messages). Should be auto-deleted by IBM MQ.
• ⚠️ IBM MQ 8.0.4 bug - Temporary queues may not be deleted properly. Upgrade to 8.0.5+ or 9.x to resolve.

For security-conscious customers: If you want to limit what Nodinite can query, restrict the other permissions (remove +dsp +inq from object types you don't want monitored). The PCF commands will respect these restrictions.

For detailed explanation: See FAQ - About PCF Commands and Security for complete information about PCF command flow, temporary queues, security architecture, and comparison with other monitoring tools.

Remote Actions Requiring Additional Permissions

The following remote actions available in Managing IBM MQ.md may require additional permissions beyond monitoring:

Note

If you plan to use Purge Queue, Remove Message, or Download Message remote actions, add +clr and +get permissions to the relevant queues.

Optimized Permission Sets

Based on your monitoring configuration checkboxes (Queues, Topics, Channels, Listeners), choose the appropriate permission set below:

Base Permissions (Always Required)

These permissions are always required for any Nodinite monitoring:

# Connect to Queue Manager - REQUIRED for all monitoring
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp

# Admin Command Queue - REQUIRED to send PCF commands to IBM MQ
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put

# Model Queue - REQUIRED to receive responses from IBM MQ via dynamic queues
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

Option A: Monitor Everything (Recommended)

Use this if

All checkboxes enabled (Queues + Topics + Channels + Listeners)

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# Queue Monitoring (state, age, count, quota, dead letter)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq

# Topic Monitoring (subscription status - automatically discovered)
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp

# Channel Monitoring (state, includes client connections)
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp

# Listener Monitoring (state)
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp

Option B: Monitor Queues Only

Use this if

Only Queues checkbox enabled

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# Queue Monitoring ONLY
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq

Option B2: Monitor Topics Only

Use this if

Only Topics checkbox enabled

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# Topic Monitoring ONLY (automatically discovers all topics)
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp

Option C: Monitor Channels Only

Use this if

Only Channels checkbox enabled

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# Channel Monitoring ONLY (includes client connections)
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp

Option D: Monitor Listeners Only

Use this if

Only Listeners checkbox enabled

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# Listener Monitoring ONLY
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp

Option E: Full Monitoring + Remote Actions

Use this if

You want monitoring AND remote actions (Purge Queue, Remove Message, Download Message)

# Base Permissions (always required)
setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

# All Monitoring (queues, topics, channels, listeners)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp

# Remote Actions (purge, remove, download messages)
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +get +clr

Tip

Security Best Practice: Start with Option A (Monitor Everything) for initial setup. Once you understand your monitoring needs, switch to a more restrictive option based on your checkbox configuration.

Legacy Permission Commands (For Reference)

The following commands were used in previous versions. They grant permissions to object types that some environments may not need based on monitoring configuration.

These commands are kept for backward compatibility but are not recommended for new installations:

setmqaut -m QM1 -t qmgr -p "mqadmin" +connect +inq +dsp
setmqaut -m QM1 -n "**" -t q -p "mqadmin" +dsp +inq
setmqaut -m QM1 -n "**" -t topic -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t channel -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t process -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t namelist -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t authinfo -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t clntconn -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t listener -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t service -p "mqadmin" +dsp
setmqaut -m QM1 -n "**" -t comminfo -p "mqadmin" +dsp
setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -p "mqadmin" +dsp +inq +put
setmqaut -m QM1 -n "SYSTEM.DEFAULT.MODEL.QUEUE" -t q -p "mqadmin" +dsp +get +inq

Warning

These legacy commands grant unnecessary permissions to object types that may not be monitored in your environment (processes, namelists, authinfo, services, comminfo). Use the Optimized Permission Sets above instead to follow the principle of least privilege and only grant permissions for the monitoring features you have enabled.

Troubleshooting MQRC_NOT_AUTHORIZED

When you log in to the IBM MQ Broker, the Nodinite IBM MQ Monitoring Agent may receive an MQRC_NOT_AUTHORIZED error. You will see this error in the Monitor Views and in the rolling Diagnostics file.

Please review IBM's documentation 2035 MQRC_NOT_AUTHORIZED when connecting to IBM MQ from WebSphere Application Server to find and apply the proper solution for your environment.

IBM Integration Bus Logging Prerequisites (Optional)

^{New 7.2.0}

If you plan to use the IBM MQ Monitoring Agent for logging IBM Integration Bus or App Connect Enterprise (ACE) Monitoring Events, ensure the following additional prerequisites are met:

IBM Integration Bus / ACE Environment

• IBM Integration Bus 9, 10 OR IBM App Connect Enterprise 11, 12, 13
• Monitoring Profiles configured to emit Monitoring Events to IBM MQ queues
• See IBM Integration Bus Logging for detailed configuration steps

Queue Configuration for Logging

Monitoring Event Queues

• Queues receiving IBM Monitoring Events must have 'Default read ahead' set to 'No'
• Service account must have GET and BROWSE permissions on logging queues
• Example queue names: IIB.MONITORING.EVENTS, ACE.AUDIT.QUEUE

Bad Message Queue (Recommended)

• Configure a separate queue for malformed Monitoring Events
• Example: IIB.MONITORING.BADMESSAGES
• Helps troubleshoot parsing errors and event format issues

Nodinite Logging Configuration

• Logging Agent Configuration created in Nodinite Administration → Log Management → Logging Agents
• LogAgentId obtained from configuration for use in agent settings (numeric ID)
• Log API accessible from agent server (for example https://nodinitesrv:40002/LogAPI/; the host and port come from your environment's settings in the Nodinite Portal (Servers step)); open the port as described in Between the IBM MQ Monitoring Agent and the Log API

Message Type and Search Field Configuration (Recommended)

To make IBM Monitoring Events searchable by business data:

• Message Types configured to identify event payload structure (Order, Invoice, Shipment, etc.)
• Search Field Expressions defined to extract business identifiers (Order IDs, Customer Names, Transaction codes)
• See IBM Integration Bus Logging - Message Type Configuration for detailed setup

Tip

Unified Agent Benefits: The IBM MQ Monitoring Agent v7.2.0+ handles both monitoring (queue depth, channels) and logging (IIB/ACE events) in a single installation. Configure monitoring in the Monitoring tab and logging in the Logging tab of the Remote Configuration modal.

Frequently asked questions

Find more solutions and FAQs for the Nodinite IBM MQ Monitoring Agent in the Troubleshooting user guide.

Next Steps

Add or manage a Monitoring Agent Configuration
Installing the IBM MQ Monitoring Agent

Related Topics

Administration
IBM MQ Monitoring Agent
Monitoring Agents